Field of the Invention
Embodiments provide systems and methods for traversing an application layer gateway firewall during the establishment of an RTC communication connection between an RTC client and an RTC server. Computer programs and machine-readable data carriers are also provided.
Background of the Related Art
Embodiments reported herein generally concern traversing of an application layer gateway firewall (hereinafter usually referred to in brief as “firewall”), which refers to data packets passing through such a firewall, for example during communication by means of Voice over IP (VoIP) or Video over IP. These types of communication fall under the category of Real-Time Transport Protocol communication (RTP communication). The following description refers but is not limited to a particular application of this RTC communication (RTC=real-time communication), which is WebRTC communication, carried out via a Web browser.
Firewalls are always an obstacle to the transmission of communications via VoIP or Video over IP. This is due to the UDP (User Datagram Protocol) port numbers negotiated dynamically in VoIP standards (H.323, SIP[RFC3261], etc.) for the RTP voice or video packets (RTP=Real-Time Transport Protocol, see [RFC3550]).
With precisely specified standard signaling protocols (H.323/H.245 (H.323 uses H.245 to handle media data), SIP/SDP (Session Initiation Protocol/Session Description Protocol), XMPP/Jingle (Extensible Messaging and Presence Protocol), MGCP (Media Gateway Control Protocol) [RFC3435], etc.), firewall manufacturers can dynamically track signals by implementing certain protocol portions (the signaling portions that are relevant to handling the UDP port numbers). This allows the firewall to open and close the dynamically negotiated UDP ports for the voice-video RTP packets to be transmitted. This known principle is also known as a firewall application layer gateway (=ALG firewall or simply firewall).
Because the signaling protocol for WebRTC is not standardized, any manufacturer can use his own proprietary protocol or alternatively can build on known protocols. Ultimately, however, ALG firewall manufacturers have the problem that they cannot build on a fixed signaling protocol, as would be the case with SIP/SDP, for example, and also cannot inspect it to get the port information in the signaling messages.
For a better understanding, FIG. 5 shows a brief outline of the traversing of an ALG firewall as is currently possible for “SIP over WebSockets.” First a browser 22 sends a message N01, “HTTP request,” to a Web server 32, which replies to it with a message N02, “HTTP response,” on a functional unit 24 (for JavaScript/HTMLS), whereby an HTTP connection is established. In an upgrade procedure, or more precisely in message N91, which the WebRTC client 20 on the WebSockets server 34 sends from the HTTP connection to a WebSockets connection as a “WebSockets upgrade request,” the use of SIP between the WebRTC client 20 and the WebSockets server 34 is managed. This allows the firewall 40 to recognize that SIP is being used. Here it is also possible, of course, to manage other standardized protocols, such as XMPP (XMPP does not use an SDP, only Jingle. Jingle is the corresponding XMPP expansion that RTC allows), H.323, MGCP. After the WebSockets server 34 receives an upgrade response at message N92, the WebRTC client 20 sends a message N93 on the WebRTC server 30, whereupon the firewall 40 looks for SDP data based on the known SIP/XMPP structures and opens the corresponding RTP ports. This cooperation is acknowledged by a corresponding message N94 with an SDP reply from the WebRTC server 30 on the WebRTC client 20. Next, media data can be exchanged, for which other protocols, such as RTP (real-time protocol), STUN (Session Traversal Utilities for NAT, NAT=Network Address Translation), ICE (Interactive Connectivity Establishment), are used.
The WebSockets protocol optionally includes a field that identifies the signaling protocol used (SIP in this example). This is shown, for example, in an info box 14 under “Browser Request” and “Web Server Response.”
The problem with WebRTC in this interchange is that the signaling protocol for WebRTC is not standardized. This means that every WebRTC server must determine how it will handle signaling communication with its WebRTC client. With this proprietary WebRTC signaling approach, it is not possible for firewall manufacturers to produce general ALG firewall solutions for traversing or crossing firewalls, known as WebRTC Traversal. This can lead to problems with generating WebRTC solutions.
WebRTC is relatively new to commercial applications. However, WebRTC is on the way to becoming a dominant technology for Web-based real-time communication.
There are multiple known firewall techniques for WebRTC that are considered for firewall traversal for WebRTC:
a. As for SIP or H.323, certain UDP port ranges in the firewall can also be opened permanently for WebRTC. However, for companies with restrictive security requirements, this is often not desirable.
b. HTTP (Hypertext Transfer Protocol) tunneling: Most firewalls have one port always open. This is the TCP port 80 (TCP=Transmission Control Protocol), through which the HTIP data traffic [see RFC2616] also runs (TCP/http port). The idea is to form a TCP tunnel between the WebRTC client and a TURN server (Traversal Using Relays around NAT, NAT=Network Address Translation, see RFC5766) on the other side of the firewall (“TURN access via TCP”) and use it to channel UDP/RTP voice/video packets and data packets through the firewall. Some firewalls/companies are so restrictive that they will not accept HTTP traffic from any client, but instead only that coming from a specific internal server (HTIP proxy). In this case, the WebRTC browser must order the HTTP proxy, using the known HTTP-CONNECT method [RFC2817], to generate the aforementioned TCP tunnel through the firewall, to be used later for the TURN protocol. In another version of this discussion, in IETF, for example, a “TURN over WebSockets” tunnel through the firewall can be used [draft-chenxin-behave-tum-WebSocket].
This HTTP tunnel solution is basically possible, but requires that several conditions be met for uninterrupted use. It must be established,                That the WebRTC client (browser) has implemented the described features (e.g., HTTP CONNECT). This depends upon the browser manufacturer (Google, Microsoft, Mozilla, etc.). For mobile WebRTC clients like smartphones and tablets (native WebRTC app),        the method itself must be implemented. the company has and supports the required infrastructure (HTTP proxy),        the WebRTC solution provider has installed a TURN server behind the firewall as part of its solution.        
c. Firewall/Port Control Protocol [RFC6887] (e.g., Cisco). The idea is that the WebRTC client, before it sends a voice or video packet, gives the firewall a command via its own protocol to open a certain UDP port. Firewall control protocols have been known since around 2003. In practice, however, this approach has not yet succeeded, due among other things to security, authentication, and authorization issues. Most companies (CIOs, IT departments) do not want their firewalls to be “controlled” by multiple clients or servers.
d. Port multiplexing: With this approach, some or all RTP streams for a WebRTC call (e.g., all audio and video streams for a call), or even all RTP streams for multiple or all calls on the same system, can be transmitted through a single UDP port. This approach alleviates the firewall port problem in that fewer port resources are needed, but it does not solve the basic problem of first having to overcome the restrictive firewall. To date, no manufacturer of WebRTC clients or servers supports port multiplexing in conjunction with SIP/XMPP/H.323-based systems (optional). Port multiplexing is particularly an option for WebRTC solution manufacturers with large to very large scaling requirements (e.g., public, residential services, e.g., Google, etc.).